The reason I didn't set it to 2018 before was that it broke older cargo versions. Because tokio-async-await is in the workspace, if cargo did not understand the edition key, it would crash.

I'm not sure what changed to make CI pass, so I would do a bit more investigation first.

our CI system updated to the latest nightly and started to fail builds, it has to be something with today's nightly update

I also can see async fn used in tokio crate, so i'd imagine similar issue there

my apologies, our original error came from the tokio crate itself, not just tokio-async-await

error[E0670]: `async fn` is not permitted in the 2015 edition
 --> ...\.cargo\registry\src\github.com-1ecc6299db9ec823\tokio-0.1.15\src\async_await.rs:3:1
  |
3 | async fn map_ok<T: StdFuture>(future: T) -> Result<(), ()> {
  | ^^^^^

nightly-x86_64-pc-windows-msvc rustc 1.34.0-nightly (7e001e5c6 2019-02-27)

The reason I didn't set it to 2018 before was that it broke older cargo versions. Because tokio-async-await is in the workspace, if cargo did not understand the edition key, it would crash.

Rust 1.26 does not know the edition key, so the build passes, but it fails on Rust 1.27-1.30.

Recently some of our builds started to fail with error in tokio-async-await (i suspect fresh nightly came out):

error[E0670]: async fn is not permitted in the 2015 edition

This change is due to rust-lang/rust#58678 and applies nightly-2019-02-28 (7e001e5c6 2019-02-27) or later.

Also, it cannot avoid this error by change tokio-async-await to 2018 edition (the current tokio-async-await does not have async fn, only tokio has async fn).

I think the only option here will be to remove usage of the async keyword in tokio proper...

tokio-await-async has some async fn in examples, perhaps it makes sense to keep it edition=2018
as for tokio itself - i think @carllerche solution is the lesser of all evils

Closing in favor of #940. Thanks for doing the initial debugging / work though 👍